fix(ios): stop the companion shipping every build as 1.0 (1) - #231
Merged
Conversation
The TestFlight build number never reached the bundle. xcodegen's default for CFBundleVersion is the literal "1", and because `info.path` sets INFOPLIST_FILE Xcode only substitutes $(...) references in that file, so the CURRENT_PROJECT_VERSION that build-ios-testflight.sh passes on the archive command line was silently discarded. Confirmed against the one ipa that has actually shipped (run 30574301994): it reports 1.0 (1), not the run id. That is worse than a wrong label. App Store Connect recorded build 1 under version 1.0, so the next upload would have been rejected as a duplicate bundle version. The lane worked exactly once and was then blocked. Both plists now reference the build settings, so the injected number reaches the app and the widget together, which App Store validation requires them to match on. MARKETING_VERSION moves 0.1 -> 1.0 to match the record that already exists in App Store Connect rather than pushing the version string backwards. The pre-upload verification checked entitlements but never the version, which is why this shipped. It now reads CFBundleVersion back out of the signed app and the signed appex and refuses to upload when either does not match the number the run computed. Also adds a version row to the phone, on both the pairing screen and the workspace list. The app previously displayed nothing about itself, so there was no way from the phone to tell which build was installed. The row is selectable so the build number can be copied and compared against a run. Verified by building with CURRENT_PROJECT_VERSION=424242: app and widget both report 1.0 (424242). Before this change both reported 1.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this does
The phone companion has been shipping every TestFlight build with the same version and build number,
1.0 (1). That is why there is no way to tell, from a phone, whether the installed app is current. It also quietly blocked the release lane: App Store Connect already recorded build1under version1.0, so the next upload would have bounced as a duplicate. The lane worked once, on 30 July, and has been stuck since.This makes the build number actually reach the app, adds a check so it cannot silently stop reaching it again, and puts the version on screen in the app so the question is answerable from the phone.
Summary
ios/ProgramaSpike/project.ymldeclaresCFBundleShortVersionStringandCFBundleVersionas$(MARKETING_VERSION)/$(CURRENT_PROJECT_VERSION)on both targets. xcodegen's defaults for those keys are the literals1.0and1, and sinceinfo.pathsetsINFOPLIST_FILE, Xcode substitutes only$(...)references. The valuebuild-ios-testflight.shpasses on the archive command line was being discarded.MARKETING_VERSIONgoes0.1to1.0. Now that the setting reaches the bundle, leaving it at0.1would push the version string backwards against a record that already exists in App Store Connect.scripts/build-ios-testflight.shreadsCFBundleVersionback out of the signed app and the signed appex and refuses to upload if either does not match the number the run computed. The existing verification covered entitlements only, which is why this shipped.AppVersion.swiftplus a version row on the pairing screen and the workspace list. The app displayed nothing about itself before. The row is selectable so the build number can be copied and compared against a workflow run.Info.plistwas tracked while the app's was ignored. Untracked for symmetry, since a committed copy of a generated file is what hid this.Test plan
xcodegen generateemits both plists with$(MARKETING_VERSION)/$(CURRENT_PROJECT_VERSION)CURRENT_PROJECT_VERSION=424242, expect app and widget plists to both read1.0 (424242). Before this change both read1.1.0 (1)ios-testflight.yml; expect the new bundle-version check to pass and the upload to be accepted rather than rejected as a duplicateStill open
Whether the build appears in your TestFlight app is a separate, portal-side question. This fixes the versioning, not tester-group assignment. Aligning the companion's marketing version with the Mac app's
0.3.0is deliberately not done here, because it would move the version string backwards.